3. Database Maintenance
Database
maintenance is divided into two parts: store mailbox maintenance and
ESE database maintenance. Store maintenance includes performing cleanup
within the database; ESE database maintenance includes online database
scanning (database checksum), defragmentation, and compaction.
3.1. Database Cleanup
Database cleanup
involves identifying newly disconnected mailboxes and evaluating the
deleted item retention period on deleted messages and mailboxes and
purging any items that have expired. Database cleanup is now the only
task that is, by default, configured to run during the online
maintenance window. Although online maintenance no longer consumes as
many resources as it did previously, it is recommended to schedule the
maintenance window after the backup window. This will allow backups to
capture data before they are purged from the database. Configuring the online maintenance schedule is shown in Figure 1.
3.2. Online Database Scanning
The integrity of data within the
database is of the utmost importance—if there is a physical page
corruption, it is important to know about it so that something can be
done. Often this type of corruption is due to a problem with the
underlying storage. In Exchange Server 2007 RTM and earlier versions,
each page was scanned during backups using the streaming API. With the
deprecation of the streaming backup API in Exchange Server 2007 and the
removal of it in Exchange Server 2010, another facility to ensure data
integrity was needed. In Exchange Server 2007 SP1 an option was
introduced to run a database checksum during the scheduled online
maintenance window.
In Exchange Server 2010, the default setting allows the online database scanning
to run in the background continuously. Alternatively, the online
database scan process can be set to run only during the schedule online
maintenance window; however, because of the time it takes to complete,
this is only recommended for databases smaller than 1 terabyte (TB).
The best practice is to leave the default setting and allow the
scanning to run continuously.
3.3. Defragmentation and Compaction
Defragmentation and compaction happen at run time and are balanced to provide data contiguity rather than to optimize space. Table 1 summarizes each type of online maintenance activity and how they have been improved in Exchange Server 2010.
Table 1. Comparing Online Database Maintenance Operations
| DATABASE FUNCTION | EXCHANGE SERVER 2007 WITH SERVICE PACK 1 | EXCHANGE SERVER 2010 |
|---|
| Cleanup | Performed during online defragmentation, which occurs during online maintenance | ESE
performs cleanup at run time when a store hard delete occurs. This
happens during dumpster cleanup during the online maintenance. |
| Database checksum | When configured, half of OLD maintenance window reserved for sequential scan (Checksum), manual throttle. Active DB copy only. | Two options (both active and passive copies):
Run DB Checksum in the background 24 x 7 (default). Run DB Checksum during online maintenance.
|
| Maintain contiguity | N/A (compaction activities during online defragmentation prevent data contiguity). | Database is analyzed at run time and is defragmented in the background. |
| Space compaction | Database is compacted and whitespace is reclaimed during online defragmentation. | Database is compacted and space reclaimed at run time. |
3.4. Offline Maintenance
One of the most
frequently asked questions continues to be, "How often should you do an
offline defragmentation of a database?" The trigger of this question in
previous versions of Exchange Server was often Event ID 1221, which
detailed the amount of free space available within each database after
a full online database defragmentation pass was completed. Many
messaging administrators would see this free space as an indicator of
inefficiency and want to reduce the size of the database to improve
performance and reduce the backup size. Because defragmentation and
compaction are now continuous processes in Exchange Server 2010, there
is no longer a point in the process when the free space within the
database base is published to the event log. There is a way, however,
to get this information using the Exchange Management Shell. For
example, the cmdlet to find the free space in Dallas-EX01-MB04 would
look like this:
Get-MailboxDatabase Dallas-EX01-MB01 -Status | Format-List AvailableNewMailboxSpace
Note: When using the Get-MailboxDatabase cmdlet, the –Status
switch must be specified to be able to view the available space,
whether online maintenance is running, whether the database is mounted,
or whether a backup is in process. If the –Status switch is not specified, the information returned by the cmdlet is retrieved from Active Directory Domain Services. When the –Status switch is specified, the additional information is retrieved directly from the Mailbox server.
As with previous versions
of Exchange, even with a significant amount of free space available in
the database, more efficient ways are available for reclaiming this
space. Using database tools such as ESEUtil.exe requires that the database be taken offline and that enough space is available on disk to complete the maintenance. Although the performance of ESEUtil
has improved, it still requires extended downtime for all mailboxes
hosted within that database. A much more reasonable approach would be
to create a new blank database and move all of the mailboxes from the
bloated databases into the newly created database. For example, the
command to move all mailboxes from Dallas-EX01-MB02 into
Dallas-EX01-MB22 would look like this:
Get-Mailbox -Database Dallas-EX01-MB02 | New-MoveRequest -Local -TargetDatabase Dallas-
EX01-MB22
If a physical corruption
is found in the database during the online database scanning (database
checksum), this same process can be used to move all mailboxes to a
newly created database and delete the problematic database. This
eliminates the need to take the database offline to repair it, which
caused extended downtime for the affected mailboxes.
